When first introduced, the mini digital video (“MiniDV”) format was truly revolutionary, not only in its treatment of the storage of video/audio media, but also in the transport used to move media between devices. With a digital tape format, timecode was no longer relegated to special purpose control tracks, but carried along with the relevant video and audio data in a cohesive frame based unit. A pure digital connection over a FireWire port allowed for data to be transferred between devices with no information loss. Beyond simple timecode, extra space was set aside in each frame to carry other types of useful embedded “metadata,” including such information as camera configuration/exposure settings, time of day, scene breaks, etc. Support for embedded data has been provided by more expensive formats for many years (e.g. SDI), but the low cost of DV/FireWire devices has greatly expanded its use to a wide range of users and hardware configurations.
In many modern non-linear editors (NLE's), most of this auxiliary information is ignored. Digital video (DV) is usually treated like any other analog based format, simply substituting FireWire driver modules for a specialized video IO board and serial port connection. While this has the advantage of allowing an existing product to support DV in a relatively painless manner, it prevents more advanced users from making use of this additional information during the editing process. This is somewhat ironic in that the use of embedded data has only grown since the format's introduction, expanding to carry such things as film pull-down cadence and logging notes. Forthcoming high definition (HD) formats are being based on the same concepts as well, with even more space allocated for custom embedded data.
One example of metadata that is currently ignored is a video's native frame rate (i.e., the rate that the video was originally shot). The native frame rate of film is typically 24 fields per second (fps). Some cameras store video at 30 fps, even though they shoot the video at 24 fps. Some of these cameras (e.g., the Panasonic DIVX100) embed the native shooting rate within each frame that they store.
When NLE's receive a video clip from another device (such as a camera or a tape deck), they typically ignore the embedded native shooting rate. However, for editing purposes, the NLE's typically convert the 30 fps video to a 24 fps video clip, because otherwise the edited video might contain artifacts. To convert the 30 fps video to a 24 fps video, existing NLE's use a variety of inefficient manual techniques. For instance, some NLE's require their users to enter the encoding cadence, where, in this example, the encoding cadence refers to the encoding technique used to map a 24 fps video to a 30 fps video. Some of these NLE's then have their users identify manually the first frame, while others use a timecode-technique that identifies the frames based on the embedded timecode. Requiring users to enter the encoding cadence is at times impractical, as the users might not know this cadence. Also, requiring the users to manually identify the first frame is inefficient since the user has to scroll through the video and identify the appropriate frame. In addition, the timecode-techniques for identifying the frame ID's can lead to inaccurate results when the timecode is not accurate. Therefore, there is a need in the art for capturing digital video efficiently by examining the metadata embedded in the digital video. There is also a need for a video-editing method that converts video, which it edits at the video's native shooting rate (e.g., 24 fps), back to another rate (e.g., 30 fps) when it comes time to output the video.
Another problem with captured digital video is inconsistency in the metadata formats of different digital-video devices of different manufacturers. While the details of the media encoding/storage are fixed by the DV specification, the exact structure and makeup of the embedded data regions of the DV frame are left open to interpretation. Due to this, various manufacturers will store different types of data in different locations. For example, Sony DVCam fills nearly all of the empty subcode blocks in VAUX with timecodes for redundancy, while Panasonic DVCPro equipment leaves these regions empty, but defines a specific location for shooting rate information. Previously, this has only been an issue for extremely poor implementations on the part of deck/camera manufacturers, with devices behaving badly when receiving a DV stream from a different deck. While most of these problems have been solved in the simple cases, issues still exist when attempting to make use of embedded data in an output stream from a computer or another device.
By default, most DV decks will regenerate the embedded data (timecode, etc . . . ) in a DV frame on record. This prevents an application or user from making use of this data to set parameters that may not be natively supported by a device. Many of the newer, semi-professional DV devices will optionally leave this embedded data alone, recoding the bit-stream to tape as the deck receives it. However, problems appear later when the deck tries to play the recorded tape, and has problems due to various bits of embedded data either not being preset, or being stored in unexpected locations.
One prior NLE uses a crude technique to encode a certain type of metadata in a DV stream that they output. This prior technique checks for timecode and/or animorphic-bit slots in the metadata of a DV stream that it is outputting. If this technique finds such slots, it records the timecode and/or animorphic bit information in these slots. This technique does not record timecode or animorphic bit data when it does not find slots in the metadata for such information.
Therefore, there is a need for a metadata-encoding method that encodes metadata in an outgoing digital video frame. For a robust implementation of embedded data support, there is also a need for a method that can modify the structure of, or add a new structure for, the embedded and auxiliary data regions in outgoing DV frames.